…color_row.tsx (elastic#271378)

Adds missing `aria-label` to both `EuiColorPicker` components in the
color format editor to resolve
`@elastic/eui/no-unnamed-interactive-element` violations.

- Added i18n `aria-label` to the text color picker: `"Text color for
item {index}"`
- Added i18n `aria-label` to the background color picker: `"Background
color for item {index}"`

```tsx
<EuiColorPicker
  color={text}
  aria-label={i18n.translate('indexPatternFieldEditor.color.textColorAriaLabel', {
    defaultMessage: 'Text color for item {index}',
    values: { index },
  })}
  ...
/>
```

### Checklist
- [x] Read and applied `.agents/skills/accessibility/SKILL.md`
- [x] Added label `a11y:agent-pr`
- [x] Fixed all files listed in the issue

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alexey Antonov <alexwizp@gmail.com>

This PR adds a new agentic skill that helps developers and AI agents
debug flaky test failures. It first provides context on the different
types of pipelines we have, and covers best practices and common
investigation pitfalls.

This skill is meant to be used by our Flaky Test Fixer agentic workflow
(we'll soon have our failed test investigator use the skill.). Local use
is just for testing purposes.

### Local testing

Invoke the skill manually by prefixing your help request with the
`/flaky-test-investigator` command:

```
/flaky-test-investigator  can you help me debug this flaky test? elastic#271165 
```

…lity area (elastic#271408)

This PR adds the `elastic/observability-bi` to the `observability` code
owner <> area mapping. Adding the team here ensures their tests are
correctly attributed to the observability area by our Scout Reporter.

Co-authored-by: Cursor <cursoragent@cursor.com>

…he query validator factory (elastic#267455)

## Summary
Fixes orphaned esql_async Elasticsearch requests left by
`esqlQueryValidatorFactory` when the user navigates away from the ES|QL
rule edit page.

The form field validator debounces a METADATA _id-injected query to
fetch columns for _id field validation. Because the validator runs
imperatively (outside React's lifecycle), two bugs allowed the request
to outlive the component:

The `debounceAsync` timer could fire after unmount, starting a brand-new
request
An in-flight request was never aborted when the component unmounted or
when a new validation superseded it

## Changes:

`esql_query_edit.tsx` — adds `abortControllerRef` and `isUnmountedRef`,
wires a `useEffect` cleanup to abort on unmount, and passes both refs to
the validator factory.
`esql_query_validator_factory.ts` — guards against post-unmount
execution via `isUnmountedRef`, aborts the previous in-flight request
before each new validation, and passes the abort signal downstream.
`esql_query_columns.ts` — accepts an optional `AbortSignal` and calls
`queryClient.cancelQueries` when it fires, propagating cancellation
through TanStack Query to the underlying HTTP request.

## How to test
Follow the reproduction steps in
elastic#266683.

…#271412)

## Summary

Plugin names like `cloud_integrations/cloud_links` (introduced by PR
elastic#270031) contain slashes that Buildkite rejects as invalid step keys.
The `configs` distribution strategy — used by the
`kibana-elasticsearch-snapshot-verify` pipeline — passed `module.name`
directly as the Buildkite step key, causing the Scout Test Run Builder
to fail. The fix sanitizes the step key while preserving the original
module name as `SCOUT_CONFIG_GROUP_KEY` so child steps can still resolve
their entry in the manifest.

## Changes

- Compute a sanitized `stepKey` from `module.name` by replacing any
character outside `[a-zA-Z0-9_-:]` with a dash
- Pass the original `module.name` as `configGroupKey` and use it for
`SCOUT_CONFIG_GROUP_KEY` in the child step env

…r in flyout !! (elastic#270936)

## Summary

Fixes a race in the overview flyout's saved-object fetch that 404s for
cross-space monitors even when the user has full access (caught by
@miguel-martinr on the 8.19 backport of elastic#265748, see [this
comment](elastic#270567 (comment))).

- `useKibanaSpace` is async, so `space` is `undefined` on the first
render. `getMonitorSpaceToAppend(undefined, spaces)` short-circuits to
`{}`, the initial `getMonitorAction.get` dispatch goes without
`spaceId`, the request hits the active space, and 404s for a cross-space
monitor.
- The retry that fires once `space` resolves is silently dropped by the
`takeLeading` saga in `monitor_details/effects.ts` because the first
request is still in flight.
- The 404 lands in `syntheticsMonitorError`, `monitorObject` stays
`null`, and the flyout body that depends on the SO
(`DetailedFlyoutHeader`, `MonitorDetailsPanel`) renders empty.

Fix: guard the dispatch on `space` being loaded. `useKibanaSpace` falls
back to `{ id: 'default' }` when the spaces plugin is absent, so the
guard always resolves.

A jest case asserts no `getMonitorAction` is dispatched while
`useFetcher` reports `space` as still loading.

## Test plan

> Setup: two spaces (e.g. `default`, `team-a`). Create a monitor in
`team-a` only, then view the Monitors overview from `default` with "Show
from all spaces" enabled (or be a `team-a` member viewing the
cross-space row).

- [ ] Open the overview flyout for the cross-space monitor from the
Monitors page. The flyout body (`DetailedFlyoutHeader` +
`MonitorDetailsPanel`) renders fully — no empty space, no 404 callout.
- [ ] Network panel: only one `GET
/s/team-a/api/synthetics/monitors/<id>` request, no preceding `GET
/api/synthetics/monitors/<id>` that 404s.
- [ ] Regression: same flow in the default space for a same-space
monitor still works.
- [ ] Regression: remote monitor flyout still skips the SO fetch
(existing `isRemote` early return is preserved).


Made with [Cursor](https://cursor.com)

Co-authored-by: Cursor <cursoragent@cursor.com>

… !! (elastic#270622)

## Summary

When the requested HMR port (`KBN_HMR_PORT` or default `5678`) is held
by another process — most commonly a leftover `@kbn/rspack-optimizer`
worker from a previous dev session or a sibling Kibana checkout — the
optimizer was failing the entire build with a bare `listen EADDRINUSE`
and logging a misleading `Waiting for changes to fix errors...`. Kibana
would still come up, but no bundles were ever emitted, so the browser
saw a 404 on `/<basePath>/<buildShaShort>/bundles/kibana.bundle.js`.

This PR makes `HmrServer.start()`:

- Retry on an OS-assigned ephemeral port when the requested port is in
use.
- Log a single warning explaining what happened, including a `lsof -i
:PORT` hint.
- Let the build proceed normally.

Since the bundled HMR client reads the resolved port from the compile
config (`run_build.ts` passes `hmrPort` from `hmrServer.start()` into
`createSingleCompileConfig`), switching ports is safe at the network
layer.

It also relaxes the env-var parsing so `KBN_HMR_PORT=0` is now a valid
explicit opt-in to ephemeral mode (used by the unit test to avoid
depending on `5678` being free on the host where tests run).

## Reproduction (before the fix)

```bash
# Simulate the zombie worker
node -e "require('http').createServer().listen(5678,'127.0.0.1')" &
KBN_USE_RSPACK=true yarn start
```

Result before this PR:

```
[error][@kbn/rspack-optimizer] Build failed: listen EADDRINUSE: address already in use 127.0.0.1:5678
[info ][@kbn/rspack-optimizer] Waiting for changes to fix errors...
```

…followed by `Kibana is now available` but `GET
/<basePath>/XXXXXXXXXXXX/bundles/kibana.bundle.js -> 404`.

With this PR:

```
[warning][@kbn/rspack-optimizer] HMR port 5678 is already in use (likely a leftover @kbn/rspack-optimizer worker — check \`lsof -i :5678\`). Falling back to an ephemeral port.
[success][@kbn/rspack-optimizer] RSPack build completed — 1 entry, 309.16 MB
```

## Test plan

- [x] Existing `HmrServer` jest tests still pass (`node scripts/jest
packages/kbn-rspack-optimizer/src/hmr/hmr_server.test.ts`).
- [x] New cases: fallback port is allocated, warning is emitted with the
right message, SSE traffic works on the fallback port.
- [x] Type-check on `packages/kbn-rspack-optimizer/tsconfig.json`.
- [x] ESLint on changed files clean.
- [ ] Manual repro on local dev with port 5678 squatted — optimizer
falls back, `kibana.bundle.js` served, UI loads.

Made with [Cursor](https://cursor.com)

Co-authored-by: Cursor <cursoragent@cursor.com>

…anager UI (elastic#271377)

Two `EuiInMemoryTable` instances in the drilldown manager UI were
missing the required `tableCaption` prop, violating
`@elastic/eui/require-table-caption`.

### Changes

- **`drilldown_template_table`** — Added `tableCaption` with i18n
string: *"Drilldown templates"*
- **`drilldown_table`** — Added `tableCaption` with i18n string:
*"Drilldowns"*

```tsx
<EuiInMemoryTable
  tableCaption={txtTableCaption}
  items={drilldowns}
  // ...
/>
```

Captions describe the dataset per EUI accessibility guidelines and use
`i18n.translate` for localization.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Alexey Antonov <alexwizp@gmail.com>

## Summary

Today the entity_analytics test trees (`test_suites/entity_analytics`,
`cypress/e2e/entity_analytics`, `cypress/tasks/entity_analytics`) are
co-owned by `@elastic/contextual-security-apps` +
`@elastic/security-entity-analytics`. The two teams actually own
different feature areas inside those trees, so the broad co-ownership
causes:

- review pings and skipped-test attribution to the wrong team;
- `team-auto-tests-stats` inventory reports double-counting skipped TCs
;
- a silently-overridden `entity_store/ → @elastic/core-analysis` line
(the broad co-ownership was winning on last-match).

This PR replaces the broad co-ownership with per-feature lines so each
test subtree maps to its actual owning team:

| Path | Owner |
|---|---|
| `test_suites/entity_analytics/entity_store/` |
`@elastic/core-analysis` |
| `test_suites/entity_analytics/entity_resolution/` |
`@elastic/contextual-security-apps` |
|
`test_suites/entity_analytics/{entity_details,monitoring,watchlists,risk_engine,risk_score_maintainer,utils}/`
| `@elastic/security-entity-analytics` (broad default) |
| `cypress/e2e/entity_analytics/entity_flyout*`,
`entity_analytics_home/entity_analytics_home_page.cy.ts`,
`entities_table.cy.ts`, `entities_table_grouping.cy.ts` | co-owned:
contextual-security-apps + security-entity-analytics |
|
`cypress/e2e/entity_analytics/{asset_criticality_upload_page,dashboards,host_details,hosts,priv_mon,watchlists}`
| `@elastic/security-entity-analytics` (broad default) |
| `cypress/tasks/entity_analytics/entity_flyout_resolution.ts` |
`@elastic/contextual-security-apps` |
| `cypress/tasks/entity_analytics/privmon.ts` |
`@elastic/security-entity-analytics` (broad default) |
| `cypress/tasks/entity_analytics/entity_analytics_home.ts` | co-owned |

### Heads-up for owners

- `@elastic/core-analysis` — the Entity Store API integration tests
under `test_suites/entity_analytics/entity_store/` (the largest
skipped-test cluster, ~37 skipped TCs) now route to your team for
reviews and CI failure attribution. The earlier `@elastic/core-analysis`
assignment for this directory was being silently overridden, so
operationally this is closer to formalizing what the file always
claimed.
- `@elastic/security-entity-analytics` — no new attribution; your
Monitoring, Watchlists, Risk Engine, Risk Score Maintainer, Entity
Details, and Cypress (priv_mon, hosts, dashboards, watchlists,
asset_criticality) tests no longer share ownership with
contextual-security-apps, so review-request distribution gets a bit
cleaner.

### Checklist

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
\`release_note:breaking\` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] The PR description includes the appropriate Release Notes section,
and the correct \`release_note:*\` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [ ] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable \`backport:*\` labels.

### Identify risks

- **Low** — CODEOWNERS-only change. No code or test behavior is
modified.
- **Operational impact for core-analysis**: PR review requests on the
entity_store API integration tests now route to them rather than the
previous co-owned set. The current line in CODEOWNERS already nominally
assigned this path to them, but was silently overridden — so for some
team members this may look new. Recommend a quick Slack heads-up.

…lastic#270027)

Plugins should not async load chunks during plugin setup or start
because:
* Hides true page load impact from page load bundle size - cheats
limits.yml metrics
* Causes more work for browser to async load code in separate HTTP
requests.

In the before image, notice how 2 reporting chunks are loaded on initial
home page load
<img height="400" alt="Screenshot 2026-05-19 at 1 31 08 PM"
src="https://github.com/user-attachments/assets/d68d0419-1618-4a45-b06a-d4f1d56bccff"
/>

In the after image, notice how 0 reporting chunks are loaded on initial
home page load
<img height="400" alt="Screenshot 2026-05-19 at 1 30 49 PM"
src="https://github.com/user-attachments/assets/935ac43f-7cd1-4ce3-ae73-a399efa03130"
/>

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…iToolTip (elastic#271484)

Relates to elastic/eui#9566

> [!IMPORTANT]
> These changes **should be carefully tested visually by each code
owner.** Wrapping with `EuiToolTip` instead of passing `title` leads to
another DOM node and can potentially break the layout. In such cases, I
would appreciate committing appropriate fixes to this PR directly, I
cannot possibly setup and run all Kibana functionalities to fix every
regression.

This PR:

- wraps ALL `EuiButtonIcon` with `EuiToolTip`, the content is the same
as `aria-label`, any `title` passed to `EuiButtonIcon` is removed,
- changes several `title` cases (not truncation related) to use
`EuiToolTip` instead (if applicable).

---------

Co-authored-by: Alexey Antonov <alexwizp@gmail.com>

…5151)

## Summary

Adds a GitHub Actions workflow that **bulk-triages** open issues
carrying the
[needs-team](https://github.com/elastic/kibana/issues?q=state%3Aopen%20label%3Aneeds-team&page=1)
label (currently 500+ issues which needs to be triaged!). Instead of
reacting to individual label events, the workflow runs on a schedule
(every hour) and can also be triggered manually via
[workflow_dispatch](https://github.com/elastic/kibana-automated-triage/actions/workflows/triage-bulk.yml).

It calls the reusable workflow at
[`elastic/kibana-automated-triage/.github/workflows/triage-bulk.yml`](https://github.com/elastic/kibana-automated-triage)
to suggest team assignments using AI (Gemini). Here is an example run:
https://github.com/elastic/kibana-automated-triage/actions/runs/25668944498/job/75348762511

<img width="1583" height="1207" alt="Screenshot 2026-05-11 at 14 15 44"
src="https://github.com/user-attachments/assets/830d4bba-64ba-4b31-877d-4ee5c731745a"
/>

### How it works

| Trigger | Behaviour |
|---------|-----------|
| `schedule` (hourly cron) | Triages up to 10 open `needs-team` issues
per run, skips the ones with low triaging confidence |

### Required secret

`GEMINI_KEY_ISSUE_TRIAGE` — Gemini API key (already added to the repo).

### Checklist

- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [x] Review the [backport
guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-backport-process)
and apply applicable `backport:*` labels.

### Identify risks

Does this PR introduce any risks?

- **Low risk**: The workflow only runs on a cron schedule or manual
dispatch, calling an external reusable workflow. No code changes to
Kibana itself. If the secret is missing the workflow will simply fail
silently. This PR adds internal CI tooling and does not affect end
users.

…astic#271759)

## Summary

Fixes an incorrect API route path in the `run_script` response action
OpenAPI schema.

The path was defined as `/api/endpoint/action/runscript` but the correct
route is `/api/endpoint/action/run_script`.

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

## Summary

### What was migrated

FTR Configs:
-
x-pack/platform/test/functional_basic/apps/transform/feature_controls/config.ts
-
x-pack/platform/test/functional/apps/cross_cluster_replication/config.ts
-
x-pack/platform/test/functional/apps/index_lifecycle_management/config.ts
- x-pack/platform/test/functional/apps/management/config.ts 
-
x-pack/platform/test/functional/apps/transform/feature_controls/config.ts

specific FTR Test files:
-
x-pack/platform/test/functional/apps/api_keys/feature_controls/api_keys_security.ts
-
x-pack/platform/test/functional/apps/index_management/feature_controls/index_management_security.ts
-
x-pack/platform/test/functional/apps/license_management/feature_controls/license_management_security.ts
-
x-pack/platform/test/functional/apps/remote_clusters/feature_controls/remote_clusters_security.ts


### What the deleted FTR tests were doing
The feature-controls suites each launched a full browser, loaded a role,
navigated to `Stack Management` and checked whether the nav link and
section items appeared or were hidden. The same pattern repeated 9 times
— once per plugin — with each running sequentially in its own FTR config
(separate server boot).

The remaining suites tested ILM policy creation/cloning/read-only flows,
CCR home page rendering, and the Create Data View wizard — all
straightforward UI flows with no role-matrix complexity.

### Coverage after migration
Specs | Location | What they cover
-- | -- | --
nav_access.spec.ts | management/test/scout/ui/ | Stack Management nav
link appears for kibana_admin, absent for global_dashboard_read
data_section.spec.ts | management/test/scout/ui/ | Data section items
(transform, ILM, CCR, index management) gated by ES cluster privileges
other_sections.spec.ts | management/test/scout/ui/ | Ingest (logstash),
security (api_keys), stack (license, remote_clusters) section gating
ilm_home_page.spec.ts | index_lifecycle_management/test/scout/ui/ |
Smoke + multi-phase policy create → flyout → list + unsaved-changes
guard
ilm_duplicate_managed_policy.spec.ts |
index_lifecycle_management/test/scout/ui/ | Cloning a managed policy
strips _meta.managed
ilm_read_only_view.spec.ts | index_lifecycle_management/test/scout/ui/ |
read_ilm user sees list, no create button, can open flyout
cross_cluster_replication_home.spec.ts |
cross_cluster_replication/test/scout/ui/ | Both tabs and primary action
buttons visible with CCR privileges
create_data_view_wizard.spec.ts | data_view_editor/test/scout/ui/ | Data
stream accepted as source; wizard auto-detects `@timestamp`; save
navigates to detail page

### Test coverage parity
Every assertion the deleted FTR tests made is still covered:

- Role-based nav visibility: the 9 feature-controls suites each checked
one section of the sidebar — now consolidated into 3 parametrized Scout
specs that run in parallel with `workers: 2`, reusing a single server
boot.
- ILM flows: all 3 FTR files (`home_page`, `duplicate_managed_policy`,
`read_only_view`) migrated 1:1 to Scout. The frozen phase is
intentionally omitted (requires path.repo snapshot repository not
available in the Scout cluster) — warm + delete phases are sufficient to
cover multi-phase creation.
- CCR home: all tab/button assertions migrated; the role now correctly
includes monitor (required by `ccr.stats()`) and read_ccr (required by
`ccr.followInfo()`).
- Create Data View wizard: all assertions migrated; fixed a race
condition in the FTR version (now waits for `data-is-loading="0"` on the
`timestamp` combobox before reading its value).


### CI runtime optimisation
**Before (without server start time)**

Configs:
-
x-pack/platform/test/functional_basic/apps/transform/feature_controls/config.ts
- 1 min
-
x-pack/platform/test/functional/apps/cross_cluster_replication/config.ts
- 1 min
-
x-pack/platform/test/functional/apps/index_lifecycle_management/config.ts
- 2 min
- x-pack/platform/test/functional/apps/management/config.ts - 1 min
-
x-pack/platform/test/functional/apps/transform/feature_controls/config.ts
- 1 min

Test files:
-
x-pack/platform/test/functional/apps/api_keys/feature_controls/api_keys_security.ts
- 40s
-
x-pack/platform/test/functional/apps/index_management/feature_controls/index_management_security.ts
- 50s
-
x-pack/platform/test/functional/apps/license_management/feature_controls/license_management_security.ts
- 1 min
-
x-pack/platform/test/functional/apps/remote_clusters/feature_controls/remote_clusters_security.ts
- 50s



It takes another 1.5 min to start servers, total runtime per CI build:
**17 min**

**After (without server start time)**
-
src/platform/plugins/shared/data_view_editor/test/scout/ui/playwright.config.ts
- 29s
-
src/platform/plugins/shared/management/test/scout/ui/parallel.playwright.config.ts
- 52s
-
x-pack/platform/plugins/private/index_lifecycle_management/test/scout/ui/playwright.config.ts
- 39s
-
x-pack/platform/plugins/private/cross_cluster_replication/test/scout/ui/playwright.config.ts
- 33s

We will run them in existing lanes due to short runtime and it means no
server time to count.

total runtime per CI build: **2.5 min**

…ic#271519)

- Closes elastic#190293
## Summary
This PR adds highlighting support for ES|QL.

<img width="1905" height="866" alt="image"
src="https://github.com/user-attachments/assets/d806ccc1-165e-46f6-a7f7-57258ac03191"
/>


### How does highlighting work?
DSL and ES|QL highlights do not work in the same way:
- DSL keeps the value unchanged and return an extra 'highlight' field in
the hit that contains substrings to be highlighted.
- ES|QL directly inlines the highlighting tags inside the result value,
not additional information is received in the result.

### Implementation details
In order to leverage the current fields formatter architecture, we
decorate the Discover hit with a new `inline_highlights` field when it's
detected that the query result has been highlighted. It contains the
highlighted columns and which tags has been used for highlighting on
each of them (could be different).
Then when the field formatter receives the `hit` it can decide which
algorithm to use.
See elastic#270394 for alternatives
discussed.


### Checklist

- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratou <efstratia.kalafateli@elastic.co>

…lastic#271468)

## Summary

Replace the TaskClient-based onboarding orchestration with an
`OnboardingWorkflowClient` that wraps the workflows management API,
unifying all KI identification operations (run, status, cancel) behind
the managed onboarding workflow (`streams_ki/onboarding.yaml`).

### Key changes

- **New `OnboardingWorkflowClient`** — stream-centric interface for
running, querying, and canceling KI onboarding workflows. Each stream's
execution is keyed by a concurrency group derived from the stream name
(ensuring at most one active run per stream).
- **New route `POST
/internal/streams/{streamName}/onboarding/_execute`** — replaces `_task`
with a `discriminatedUnion` body schema supporting `schedule` and
`cancel` actions.
- **Simplified `OnboardingResult` schema** — flat structure with summary
counts (`discoveredFeaturesCount`, `persistedQueriesCount`, etc.)
instead of nested `TaskResult` wrappers.
- **New `OnboardingStatus` enum** — domain-level statuses
(`not_started`, `in_progress`, `being_canceled`, `canceled`, `failed`,
`completed`) replacing the generic `TaskStatus`.
- **Agent builder tools updated** — all three KI identification tools
(`start`, `status`, `cancel`) now accept `OnboardingWorkflowClient`
instead of `GetScopedClients`.
- **Continuous extraction workflow updated** — calls the new onboarding
endpoints and uses `OnboardingWorkflowClient.cancelAllRunning()` for
teardown.
- **Frontend hooks migrated** — `useKnowledgeIndicatorsTask` →
`useKnowledgeIndicatorsOnboarding`, `useOnboardingApi` methods renamed
(`scheduleOnboarding`, `getOnboardingStatus`, `cancelOnboarding`).
- **Old task definitions deprecated** — `streams_onboarding`,
`streams:features-identification`, and
`streams:sig-events-queries-generation` task types are annotated
`@deprecated` and kept for reference (removal in follow-up).

## Test plan

- [ ] **Onboarding from stream details view** — trigger schedule, verify
polling shows progress, cancel mid-run, verify final status
(Completed/Canceled)
- [ ] **Onboarding from discovery view** — bulk-trigger onboarding for
multiple streams, verify status indicators update correctly across the
tree table
- [ ] **Continuous extraction workflow** — enable continuous extraction,
verify eligible streams are classified correctly (candidates,
already-running, up-to-date, excluded), confirm scheduled workflows
complete end-to-end
- [ ] **Onboarding with agents** — use `ki_identification_start`,
`ki_identification_status`, and `ki_identification_cancel` tools via the
agent, verify `execution_id` is returned in status/cancel responses

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…on with EuiToolTip (elastic#271481)

Closes elastic#270161

Relates to elastic/eui#9566

> [!IMPORTANT]
> These changes **should be carefully tested visually by each code
owner.** Wrapping with `EuiToolTip` instead of passing `title` leads to
another DOM node and can potentially break the layout. In such cases, I
would appreciate committing appropriate fixes to this PR directly, I
cannot possibly setup and run all Kibana functionalities to fix every
regression.

This PR:

- wraps ALL `EuiButtonIcon` with `EuiToolTip`, the content is the same
as `aria-label`, any `title` passed to `EuiButtonIcon` is removed,
- changes several `title` cases (not truncation related) to use
`EuiToolTip` instead (if applicable).

---------

Co-authored-by: Alexey Antonov <alexwizp@gmail.com>
Co-authored-by: Ania Kowalska <63072419+akowalska622@users.noreply.github.com>

…#271765)

Closes elastic#271750


## Summary

- Dashboard filters are not inherited by the service map
- Added a few unit tests


### Before and After

#### Before

https://github.com/user-attachments/assets/c80e0f89-0f30-4187-b059-3f2b9db46396


#### After

https://github.com/user-attachments/assets/51bdd0a8-ba33-4919-ab06-9307242075dc


### Checklist

- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

## Summary

Followup to elastic#271465 which missed
these strings.

### Checklist

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [ ] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.

### Identify risks

UI labels change only.

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

… credential selector (elastic#271805)

## Summary

Fixes the consistently failing `cis_integration_gcp.ts` agentless test
(elastic#262351).

**Root cause:** When GCP Cloud Connectors are enabled (CSP package >=
`3.3.0-preview03`), the agentless GCP form now defaults to the
`cloud_connectors` credential type, which renders
`LazyCloudConnectorSetup` instead of the Launch Cloud Shell button. The
test was unconditionally asserting the Cloud Shell button, causing a
consistent failure.

**Fix:** Add `selectGcpCredentials` and `isGcpCredentialSelectorVisible`
page object helpers, then conditionally switch to `credentials-json`
before asserting the Cloud Shell button — mirroring the same pattern the
AWS test uses with `selectAwsCredentials('direct')`.

## Changes

- `add_cis_integration_form_page.ts`: Added `selectGcpCredentials` and
`isGcpCredentialSelectorVisible` page object methods
- `cis_integration_gcp.ts`: Un-skipped outer `describe.skip`, added
conditional credential type selection before asserting Cloud Shell
button

Note: The inner `describe.skip('Serverless - Agentless CIS_GCP edit
flow')` remains skipped (separate issue with `getFieldAttributeValue`
returning `[object Object]`).

## Checklist

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/GUIDELINE.md)
- [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)

## Identify risks

- Low. Only test code changed, no production code.
- The fix degrades gracefully: `isGcpCredentialSelectorVisible()`
returns false when GCP Cloud Connectors are not enabled (older package),
so no credential switch is attempted and the existing assertion
continues to work.

Made with [Cursor](https://cursor.com)

Co-authored-by: Cursor <cursoragent@cursor.com>

elastic#266468)

- When Entity Store v2 is on, the Watchlists tab shows a callout if the
store is not running (or if status fails to load).
- Create Watchlists Button and Management Table stay visible so users
can still manage watchlists.
- Smol update on props also: Watchlists props optional with defaults for
tab usage; table component only receives spaceId (matches its API).

For this issue: elastic#266453

**Screenshot:** 

<img width="2370" height="1440" alt="image"
src="https://github.com/user-attachments/assets/d881d55f-f30d-4446-a6fa-d18b1f9861c0"
/>

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

…71625)

## Summary

Creates `@kbn/ui-chrome-layout-constants` and
`@kbn/ui-chrome-layout-utils` as proper kbn-ui packages, replacing the
hand-maintained stub files that @kbn/ui-chrome-layout and
@kbn/ui-side-navigation previously used at webpack build time. The
implementation (CSS variables, layout levels, scroll utilities, and
high-contrast helpers) now lives in the kbn-ui tree and is published to
Artifactory alongside the other kbn-ui packages.

`@kbn/core-chrome-layout-constants` and `@kbn/core-chrome-layout-utils`
are retained as thin re-export shims (export * from '@kbn/ui-*') so all
existing Kibana consumers continue to work without changes. The publish
pipeline is also extended with a topological sort over kbn-ui package
dependencies (read from each package's moon.yml) so packages are always
built and published in dependency order; each package's build.sh
additionally checks and builds missing dependency targets as a safety
net for partial runs.

**_note for reviewers:_** I've moved the vault address to the previous
location as it was still failing in CI

---------

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

## Summary

This PR resolves [[Scout] Move EUI Provider from FTR to
Scout](elastic/kibana-team#3395) issue.

…astic#270348)

Closes elastic/rna-program#355

## Summary

Adds optional `version` field to `PATCH /api/alerting/v2/rules/{id}` for
optimistic concurrency control, matching the pattern already used by the
notification policy update route. Without this, concurrent updates
silently use last-write-wins.

## Changes

- **Schema**: new `updateRuleBodySchema` extends `updateRuleDataSchema`
with optional `version` (`min(1).max(256)`). Added `version` to
`ruleResponseSchema`.
- **Route**: validates with `updateRuleBodySchema`, destructures
`version` into `options`, documents `409`.
- **Rules client**: `updateRule` now accepts `options.version`. When
provided, the server enforces OCC and returns `409 Conflict` on mismatch
via the existing SO conflict mapping. When omitted, falls back to the
current server-read version (no breaking change).
- **SO service**: `create`, `update`, and `find` contracts widened to
surface `version` so it flows through to the response transform.
- **Response transform**: `transformRuleSoAttributesToRuleApiResponse`
now carries `version` through every read path

---------

Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>

Automated by
https://buildkite.com/elastic/package-storage-infra-kibana-discover-release-branches/builds/4920

Co-authored-by: elastic-vault-github-plugin-prod <elasticmachine@elastic.co>

…lastic#271892)

Reverts elastic#255151 due to cross-repos access issues as
https://github.com/elastic/kibana-automated-triage is a private repo. I
will create another workflow which would be triggered directly from
https://github.com/elastic/kibana-automated-triage with the same
schedule.

…269633)

Closes elastic/obs-ai-team#549

### Summary

Fixes a discovery gap where `observability.get_index_info`
(`get-index-patterns`) could not see Streams data streams because
discovery used `indices.getDataStream` with dash-oriented patterns
(`logs-*`), which do not match dot-hierarchy stream names
(`logs.aws-lambda-payment-gateway`).

The Elastic AI Agent with the investigation skill relies on this tool to
learn which indices exist before calling `get_logs`, field discovery,
etc. Without it, Streams-ingested data was invisible while
`platform.core.list_indices` found everything.

### Changes

- Switch data stream discovery `get_data_streams_handler.ts` from
`indices.getDataStream` to `listSearchSources` (`_resolve_index`),
matching `platform.core.list_indices`

- Add Streams hierarchy patterns:
  - `logs`
  - `logs.*`
  - `metrics`
  - `metrics.*`
  - `traces`
  - `traces.*`

alongside existing log/metric/APM patterns from
`getObservabilityDataSources`.

- Extend `extractDataset` to handle dot-hierarchy names:
  - `logs.ecs.nginx` → `ecs.nginx`

  while preserving classic Fleet parsing:
  - `metrics-system.memory-default` → `system.memory`


### Test

#### Manual

- Ingest via Elastic Streams (e.g. `streams_messy_logs`)
- Run Agent Builder with investigation skill
- Ask about the data
- Agent should call `get_index_info` and see dot-notation streams

#### Compare behavior

- Compare with `platform.core.list_indices` on the same cluster
- Both should list Streams data

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

Closes elastic/obs-ai-team#571

## Summary

**dev golden-cluster Vault path directly usable from `kbn-evals` CLI**.
This PR makes the **dev golden-cluster Vault path directly usable from
the `kbn-evals` CLI**, without needing to share secrets or maintain
local secret files. Developers now have a `dev-vault` profile.

### Changes
- Dev Vault profile support in CLI profile resolution: Added/used a
virtual profile (`dev-vault`) for runtime Vault reads.
- Vault script usability updates: Updated vault scripts
(`retrieve/upload/get_command`) with `--vault dev|ci-prod`.

### Manual smoke
- `node scripts/evals init`
- `node scripts/evals start --suite <suite-id> --profile dev-vault`

---------

Co-authored-by: Srdjan Lulic <lulic.ing@gmail.com>

…e review endpoints to support aggregation (elastic#266112)

# Summary

Migrates the existing `POST
/internal/detection_engine/prebuilt_rules/installation/_review` and
`POST /internal/detection_engine/prebuilt_rules/upgrade/_review`
endpoints to consume the same granular request shape introduced by
`rules/_search` (elastic#262307) and to generate their Zod schema from OpenAPI
(this is the source of a lot of the diff). Both endpoints now support:

- **KQL filtering** via a dedicated `filter.term` / `filter.mode` pair,
kept separate from free-text **search** (`search.term` / `search.mode`).
- **Facet aggregations** via `aggregations.counts`, returning
per-category bucket counts in a single round-trip alongside the page of
rules:
  - install-review: `tags`, `severity`
- upgrade-review: `tags`, `enabled`, `isCustomized` (and other
`GranularRulesFacetCategory` values supported by the rules search path)
- **Field selection** via a `fields` parameter to narrow Elasticsearch
`_source` for prebuilt-rule-asset documents (install-review) and to trim
`current_rule` / `target_rule` payloads (upgrade-review). A small
baseline attribute set is always merged so payloads remain convertible.
- **Multi-field `sort`** via an ordered array of `{ field, order }`
items. .

The Add Elastic Rules and Rule Updates table UIs
(`add_prebuilt_rules_table_context.tsx`,
`upgrade_prebuilt_rules_table_context.tsx`,
`use_prebuilt_rules_install_review.ts`,
`use_prebuilt_rules_upgrade_review.ts`,
`use_prebuilt_rules_upgrade.tsx`) have been migrated to consume the new
endpoint shape, sending the structured KQL filter and search term
separately but do not select fields or aggregations as part of this
work.


The original API design doc can be found [here]
(https://docs.google.com/document/d/17jeRzt1a3T4Z3mr2AJqBxyhz_peJRNHL54BUM_AHb7o/edit?tab=t.0#heading=h.pgl8rhsgahc8)
(internal).

Performance characteristics can be found [here]
(https://docs.google.com/document/d/1ZoPAH-OgdUX5WdwFAMLJIuI04PFhU7lqmj2mOmgmlQY/edit?tab=t.0#heading=h.3gyz2zlnp7d1)
(internal).

# Context

The `installation/_review` and `upgrade/_review` endpoints both grew up
around a single `filter` object that bundled UI concerns (name, tags,
customization status) together. The server re-derived a KQL string on
every fetch and, in the case of install-review, pulled the full set of
prebuilt-rule assets before narrowing in JavaScript. As the granular
filter epic moves forward, that shape no longer scales for filter /
search / aggregation extensibility.

These endpoints remain internal until the full granular epic has shipped
and the contract is stable.

# Testing

- Start Kibana locally and navigate to Security → Rules → **Add Elastic
Rules**.
- Confirm the install review table loads correctly — check the Network
tab to verify requests go to `POST
/internal/detection_engine/prebuilt_rules/installation/_review` and that
the body contains `filter`, `search`, and (when sorting) `sort`.
- Use the search box and tag filter and verify rules are filtered as
expected.
- Navigate to Security → Rules → **Rule Updates**.
- Confirm the upgrade review table loads correctly via `POST
/internal/detection_engine/prebuilt_rules/upgrade/_review` with the same
POST body shape, and that filtering by tags, customization status, and
free-text search produces the expected results.
- Call both endpoints directly via curl or Postman to verify facet
counts (`counts.tags`, `counts.severity`, `counts.enabled`,
`counts.isCustomized`, etc.) are returned and stay consistent with the
filtered set when applied.

# Checklist

Reviewers should verify this PR satisfies this list as well.

- [x] Unit or functional tests were updated or added to match the most
common scenarios
- [x] [Flaky Test
Runner](https://buildkite.com/elastic/kibana-flaky-test-suite-runner)
was used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [x] [Review the backport
guidelines](https://www.elastic.co/guide/en/kibana/current/backporting.html)
and apply applicable `backport:*` labels

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ution classic nav (elastic#269683)

## Summary

Adds Discover, Agents and Workflows app links to classic Security
Solution nav to align with the current Security Solution (solutions only
nav)

Note: Agents links (agent builder) is gated and shows only if the new AI
agent experience is active (`app/management/ai/genAiSettings`).
<img width="1665" height="530" alt="Screenshot 2026-05-29 at 10 43 10"
src="https://github.com/user-attachments/assets/f1f14c9b-b426-4c5a-8064-113551ff5ffc"
/>



<details><summary>Screenshot</summary>
<img width="230" height="794" alt="Screenshot 2026-05-18 at 14 00 04"
src="https://github.com/user-attachments/assets/99c252c7-528c-49ff-aafa-5fb8955a3305"
/>
</details> 

The changes are gated with `securityClassicNavExternalLinks` feature
flag.

> [!Note]
> There will be a follow up PR to move Agents to the top that would
depend on a [separate feature flag
](elastic#267628)

### Checklist

Check the PR satisfies following conditions. 

Reviewers should verify this PR satisfies this list as well.

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [ ] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.

### Identify risks

Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.

Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.

- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...

…RulesPackageInstallation` helper (elastic#271457)

Closes elastic#268359, closes elastic#268360, closes elastic#268548, closes elastic#268549, closes
elastic#268566, closes elastic#268567, closes elastic#268708, closes elastic#269232, closes elastic#269233,
closes elastic#269723, closes elastic#270225, closes elastic#270226, closes elastic#270318, closes
elastic#270319, closes elastic#270611, closes elastic#271178, closes elastic#271179, closes elastic#271182,
closes elastic#271183, closes elastic#271193, closes elastic#271543, closes elastic#271544.

This PR fixes flakiness in Cypress tests that use
`preventPrebuiltRulesPackageInstallation` helper.

🟢 Flaky Test Runner:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/12493

Test used to fail with `Error: Socket closed before finished writing
response`.

We are using `cy.intercept(...)` to intercept initialization flow
requests to skip package installation. However, if initialization
request also contains another flow that's unrelated to package
installation we don't mock the request. If the non-mocked request is in
flight, and during this time Cypress reloads a page (`cy.reload()`), the
request gets canceled and Cypress treats it as an error, although it's a
normal situation.

The fix is using a listener instead of `request.continue(...)`. Listener
doesn't error if test runner navigates away – it just doesn't run if
response wasn't received.

The flakiness was introduced in this PR:
elastic#266690
However, the flaky test runner didn't catch it back then because I
didn't run all the specs that were affected by the change in helper
🤦‍♂️. I updated my skill to make sure it triggers the Flaky Test Runner
for tests that use a shared helper.

…tic#271547)

Resolves elastic#271581

## Summary

- Adds recovery threshold conditions to the threshold rule builder,
allowing users to define custom recovery criteria via a guided form
- Recovery conditions are auto-derived from alert conditions (flipped
comparators) and correctly restored when editing an existing rule
- Uses `useBuilderState` context for state management, consistent with
the alert condition step (no prop drilling)
- Compressed form inputs and consistent spacing across all builder
components

## Test plan

- [ ] Create a threshold rule, select "Custom recovery", configure
conditions, save → verify recovery persists
- [ ] Reopen saved rule → verify "Custom recovery" selected with correct
conditions
- [ ] Switch to "Default recovery" and save → verify recovery resets
- [ ] Verify preview does NOT auto-open when selecting "Custom recovery"
in builder mode
- [ ] Switch default → custom → default → custom → verify conditions
re-derive from alert conditions
- [ ] Verify non-builder (ES|QL) mode still works as before

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

## Summary

We agreed to change "Export tab" to "Export tab results" for clarity in
Discover's app menu:
<img width="500"
src="https://github.com/user-attachments/assets/fb7b2e41-00be-43e8-a7bf-fb04037e553c"
/>

### Checklist

- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
- [x] Review the [backport
guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing)
and apply applicable `backport:*` labels.